System and method for transmitting ACARS messages over a TCP/IP data communication link

ABSTRACT

An ACARS messaging system according to the invention is deployed when a TCP/IP subnetwork is available to the aircraft. ACARS messages are encoded into ASN.1 notation and translated to become compliant with the TCP/IP suite of protocols. A wireless subnetwork provides the initial access point to establish the TCP/IP datalink for the ACARS message traffic. The system allows transmission of ACARS messages using low cost and high bandwidth TCP/IP networks in lieu of the private networks that carry conventional ACARS messages.

TECHNICAL FIELD

The present invention relates generally to data communication systems.More particularly, the present invention relates to a data communicationsystem for the processing and transmission of Aircraft CommunicationsAddressing and Reporting System (“ACARS”) messages using a TCP/IPnetwork.

BACKGROUND

ACARS is an addressable digital data communication system utilized bycommercial and business aircraft. ACARS was developed to enable flightoperators to communicate with the aircraft in their respective fleets.ACARS is used to transmit routine reports, data, and simple messagesbetween an aircraft and its flight operator. ACARS messages aretransmitted using AM channels to avoid overcrowding of the aircraft VHFvoice channels. Conventional ACARS messaging is described and defined bythe ARINC 618 and ARINC 620 standards.

Currently, ACARS messages traverse legacy datalinks that are expensiveand relatively slow, such as VHF channels or SATCOM links. Suchcommunication paths are adequate for communications during flight, butcan be undesirable for communications after the aircraft has landed.Historically, even after an aircraft has touched down, ACARS messagesmust be transmitted via existing systems and protocols, which may beprovided by private companies such as ARINC (in the United States) andSITA (in Europe). Since most commercial aircraft communication ishandled after touchdown, ACARS messaging can be very expensive forairlines, especially for those with very large fleets.

Accordingly, it would be desirable to have an ACARS messaging systemthat can take advantage of higher speed and less costly datacommunication systems available to aircraft after touchdown. Forexample, it would be advantageous for an ACARS messaging system toleverage existing data communication technologies such as the Internet,TCP/IP based communications, and wireless links such as 802.11 links.Furthermore, other desirable features and characteristics of theinvention will become apparent from the subsequent detailed descriptionand the appended claims, taken in conjunction with the accompanyingdrawings and the foregoing technical field and background.

BRIEF SUMMARY

A system for transmitting ACARS messages after touchdown of an aircraftincludes onboard processing logic that translates a conventional ACARSmessage into a format compatible with the TCP/IP suite of protocols. Thetranslation enables the system to transmit ACARS message content usinghigh speed networks, such as the Internet and the LAN architecturemaintained by the airline. The translation also facilitates thetransmission of ACARS message content in a manner that bypasses theconventional and costly networks maintained by ARINC and SITA.

The above and other aspects of the invention may be carried out in oneform by an ACARS messaging method that involves obtaining an ACARSmessage containing message content, encoding the ACARS message intoASN.1 format, translating the encoded message into an ACARS-IP message(compliant with TCP/IP) containing the message content, and transmittingthe ACARS-IP message between an aircraft and a message processing servervia a TCP/IP datalink.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be derived byreferring to the detailed description and claims when considered inconjunction with the following figures, wherein like reference numbersrefer to similar elements throughout the figures.

FIG. 1 is a diagram of a system environment for ACARS messaging over IP;

FIG. 2 is a schematic representation of a practical ACARS messagingsystem deployment over IP;

FIG. 3 is a simplified schematic representation of an ACARS messagingsystem according to the invention;

FIG. 4 is a simplified software architecture diagram of a communicationsmanagement unit that handles ACARS messages;

FIG. 5 is a message sequence diagram that depicts an example sequencehandled by an ACARS messaging system over IP;

FIG. 6 is a flow diagram of an ACARS messaging process;

FIG. 7 is a message sequence diagram that illustrates a simulatedacknowledgment procedure;

FIG. 8 is a message sequence diagram that illustrates a procedurerelated to ACARS message re-routing;

FIG. 9 is a message sequence diagram that illustrates a simulatedacknowledgment corresponding to a delayed downlink message; and

FIG. 10 is a message sequence diagram that illustrates a simulatedacknowledgment corresponding to an unsuccessful downlink message.

DETAILED DESCRIPTION

The following detailed description is merely exemplary in nature and isnot intended to limit the invention or the application and uses of theinvention. Furthermore, there is no intention to be bound by anyexpressed or implied theory presented in the preceding technical field,background, brief summary or the following detailed description.

The invention may be described herein in terms of functional and/orlogical block components and various processing steps. It should beappreciated that such block components may be realized by any number ofhardware, software, and/or firmware components configured to perform thespecified functions. For example, an embodiment of the invention mayemploy various integrated circuit components, e.g., memory elements,digital signal processing elements, logic elements, look-up tables, orthe like, which may carry out a variety of functions under the controlof one or more microprocessors or other control devices. In addition,those skilled in the art will appreciate that the present invention maybe practiced in conjunction with any number of data transmissionprotocols and that the system described herein is merely one exemplaryapplication for the invention.

For the sake of brevity, conventional techniques related to ACARSmessage creation, routing, and processing, TCP/IP data transmission,signaling, network control, and other functional aspects of the systems(and the individual operating components of the systems) may not bedescribed in detail herein. Furthermore, the connecting lines shown inthe various figures contained herein are intended to represent examplefunctional relationships and/or physical couplings between the variouselements. It should be noted that many alternative or additionalfunctional relationships or physical connections may be present in apractical embodiment.

An ACARS messaging system according to the invention is designed toleverage existing TCP/IP network datalinks that are available to anaircraft, thus enabling the aircraft to communicate ACARS messagecontent to a ground-based peer. Briefly, the invention relates to anapplication protocol and processing performed by the originator and/ordestination subsystems that allow ACARS messages to traverse a TCP/IPnetwork such as the Internet. From a user perspective, ACARS messagecommunications appear to be traversing conventional datalinks eventhough, in reality, the ACARS message content traverses a low cost andhigh bandwidth commercial network. Notably, ARINC or SITA need not beinvolved in ACARS traffic handled by the ACARS messaging system (unlikeair-to-ground and ground-to-air transactions over SATCOM/VHF), and theACARS message content can be transferred directly from the aircraft to aground end system (and vice versa) over the TCP/IP network without anyprocessing provided by a data service provider.

FIG. 1 is a diagram of an ACARS messaging system environment 100 inwhich a system according to the invention may be deployed. Thisenvironment 100 generally includes an aircraft 102, e.g., an aircraft ofa commercial airline, that has touched down or is close to touchingdown. Once it has landed, aircraft 102 can establish communication witha suitable TCP/IP network 104 such as the Internet. In this regard,aircraft 102 preferably includes an onboard data communication elementconfigured to establish the TCP/IP datalink. In the example embodimentof the invention described herein, a message processing server 106 iscapable of establishing communication with TCP/IP network 104. In atypical environment 100, message processing server 106 is a ground-basedunit located at the destination airport.

In practice, TCP/IP network 104 can include any number of physicaldatalinks interconnected together for purposes of routing TCP/IP trafficfrom a data source to a data destination. In this regard, the ACARSmessaging system may establish a TCP/IP datalink 108 between aircraft102 and message processing system 106 to facilitate communication ofACARS message content as described in more detail below. To handle afleet of aircraft, message processing system 106 is configured tosupport a plurality of TCP/IP connections (one per aircraft). As usedherein, a “TCP/IP datalink” is any communication link that can transportdata in compliance with the TCP/IP suite of protocols. TCP/IP datalink108 can include one or more components, including any number of wirelessTCP/IP datalinks and any number of wired TCP/IP datalinks.

FIG. 2 is a schematic representation of a practical ACARS messagingsystem deployment. In FIG. 2, aircraft 102 is schematically depicted bythe dashed lines. Aircraft 102 may include an onboard communicationsmanagement unit (“CMU”) 200 and an onboard data communication element,for example, a terminal area wireless LAN unit (“TWLU”) 202. Inpractice, CMU 200 is a line replaceable unit (“LRU”) hardware componentthat includes processing logic that supports a number of aircraftcommunication functions, including conventional ACARS messaging and themodified ACARS messaging functions described herein. CMU 200 includes atleast an ACARS router component that performs ACARS message processingand routing. The ACARS router component also includes a TCP/IP stack andprocessing logic related to ACARS message encoding and translation. In apractical implementation, the ACARS router component may be realizedwith one or more physical modules, cards, or devices (where suchmodules, cards, or devices are suitably configured to communicate witheach other and to execute independent tasks to facilitate concurrentprocessing).

In the example embodiment, CMU 200 is coupled to TWLU 202 with asuitable datalink, e.g., a 10Base-T Ethernet datalink. TWLU 202, whichmay also be an LRU, includes hardware and processing logic that supportswireless data communication between aircraft 102 and a ground-basedsystem such as the LAN maintained by the destination airport. In apractical embodiment, TWLU 202 establishes a wireless datalink 204between aircraft 102 and a wireless access point 206 associated with theground-based network. In the example embodiment, wireless datalink 204is a TCP/IP datalink. In practice, wireless datalink 204 can be realizedas an 802.11 (a, b, or g) datalink, a Bluetooth datalink, a HomeRFdatalink, a HiperLAN datalink, GPRS, wireless telephony, UMTS, SATCOM,or the like. For purposes of the commercial aircraft example describedherein, wireless access point 206 can be a ground-based unit located atthe destination airport. Wireless access point 206 is connected toTCP/IP network 104, thus establishing TCP/IP datalink 108 betweenaircraft 102 and message processing server 106.

FIG. 3 is a simplified schematic representation of an ACARS messagingsystem 300 according to the invention. FIG. 3 depicts functionalelements, data elements, and processing logic associated with CMU 200and message processing server 106. Generally, CMU 200 may include thefollowing elements: an ACARS router 302; ACARS messages 304; an ASN.1encoder 306; and a TCP/IP translator 308. Generally, message processingserver 106 may include the following elements: a TCP/IP translator 310;an ASN.1 decoder 312; ACARS message construction logic 314; and messagecontent extraction logic 316. For simplicity, FIG. 3 is directed to theprocessing and handling of an ACARS downlink message, i.e., an ACARSmessage sent from CMU 200 to message processing server 106. In apractical embodiment, ACARS messaging system 300 is configured forbidirectional message communication and, as such, both CMU 200 andmessage processing server 106 may include functional elements, dataelements, and processing logic that supports ACARS uplink messages inthe reverse direction.

Referring to CMU 200, ACARS router 302 handles incoming and outgoingACARS message traffic, including the generation and processing of ACARSmessages 304. The configuration and characteristics of conventionalACARS messages are well known to those skilled in the art and,therefore, will not be described in detail herein. Such conventionalACARS messages can include messages that comply with ARINC standards,e.g., A618 messages, A619 messages, and A620 messages. ASN.1 encoder 306is configured to encode, convert, and/or translate ACARS messages into aformat that is compliant with ASN.1. ASN.1 is a formal notation used fordescribing data transmitted by protocols, regardless of languageimplementation and physical representation of the data, regardless ofthe application, and regardless of the complexity of the data. ASN.1provides an unambiguous methodology for exchanging ACARS content betweenCMU 200 and message processing server 106. TCP/IP translator 308functions to translate, convert, and/or format the encoded ACARSmessages into corresponding ACARS-IP messages that are compliant withthe TCP/IP suite of protocols. The term “ACARS-IP message” is usedherein to distinguish such messages from conventional ACARS messages.

As described above, the ACARS-IP messages can be transmitted between theaircraft and message processing server 106 via a suitable TCP/IPdatalink, which may include one or more wireless TCP/IP datalinks.Referring to message processing server 106, the ACARS-IP messages arereceived and processed by TCP/IP translator 310. Translator 310functions to translate, convert, and/or format the ACARS-IP messagesinto corresponding data that can be processed by ASN.1 decoder 312.ASN.1 decoder is configured to decode, convert, and/or translate thisdata to remove the ASN.1 encoding performed by ASN.1 encoder 306. ACARSmessage construction logic 314 can process the decoded data to constructa received ACARS message having the conventional ACARS format.Thereafter, message content extraction logic 316 can extract any of theuseful content from the received ACARS message for further processing orhandling in any suitable manner. In lieu of “reconstruction” of the A620message, the raw data could be fed into any number of processes forappropriate handling.

The example embodiment described herein handles A618, A619, and A620messages. A618 messages are messages transmitted between aircraft 102and a ground system such as a data service provider (“DSP”). ACARSmessaging system 300 is preferably utilized to transmit A618 messagesafter touchdown of aircraft 102. Conventional ACARS messaging techniquescan be utilized to transmit A618 messages during flight. A619 messagesare “internal” messages transmitted between CMU 200 and other LRUs onaircraft 102. A620 messages are messages transmitted between a groundsystem such as a DSP and an end system (in a practical commercialaircraft deployment, the end system is maintained by the airline).

FIG. 4 is a simplified software architecture diagram of a portion of aCMU 400. CMU 400 is configured to communicate with other external LRUs402 of aircraft 102, legacy subnetworks 404 that support ACARSmessaging, a TCP/IP subnetwork 406 as described herein, and amultifunction control and display unit (“MCDU”) 408 that functions as adisplay and input device in the cockpit of the aircraft. As describedabove, CMU 400 may contain processing logic related to the encoding andtranslation of ACARS messages for transmission via TCP/IP subnetwork(s)406. CMU 400 also includes an ACARS router 410, which handles incomingand outgoing ACARS message traffic, an A619 protocol handler 412 coupledto ACARS router 410, and an A618 protocol handler 414 coupled to ACARSrouter 410.

A conventional ACARS messaging process may be performed as follows. AnLRU 402 communicates with A619 protocol handler 412, which generates asuitable A619 message for processing by ACARS router 410. ACARS router410 then communicates the message to A618 protocol handler 414, whichgenerates a suitable A618 message. The A618 message is then routed tolegacy subnetwork(s) 404. In contrast, an ACARS messaging processaccording to the invention may be performed as follows. The pilot of anaircraft can enter a message (e.g., by typing into a keyboard) into MCDU408, which is onboard the aircraft. That message is then communicated toACARS router 410 in a manner that bypasses A619 protocol handler 412.Similarly, messages sent via TCP/IP subnetwork(s) 406 can bypass A618protocol handler 414 in transit to ACARS router 410. Therefore, thetechniques of the invention can be utilized to avoid conventional A619and A618 ACARS message processing.

FIG. 5 is a message sequence diagram that depicts an example sequencehandled by an ACARS messaging system, and FIG. 6 is a flow diagram of anACARS messaging process 600. The operation of an ACARS messaging systemaccording to the invention will be described in connection with FIG. 5and FIG. 6. In FIG. 5, time is represented by the vertical scale, withtime progressing from top to bottom. FIG. 5 depicts processing orrouting performed by an ACARS router 502, which may be realized in a CMUin a practical embodiment, a TWLU 504, and a message processing server506. Process 600 and the example message sequence diagram assume thefollowing: (1) the CMU has been initialized and is operational; (2) theaircraft has landed or is otherwise within the vicinity of a wirelessaccess point such that TCP/IP connectivity can be established; (3) theground-based end system, e.g., a message processing server, ismonitoring for a TCP/IP connection from the CMU; and (4) the groundnetwork infrastructure is in place and functioning properly.

Referring to FIG. 5, Item 1 represents any event that triggers theprocessing of ACARS messages as described herein. The event mayrepresent the touchdown of the aircraft and notification of thetouchdown event to ACARS router 502, the availability of a specifiedamount of message data, the availability of a suitable TCP/IPconnection, etc. This event enables ACARS router 502 to prepare to makethe TCP/IP network connection. For example, ACARS router 502 may processthe ground-based IP address and/or hostname of message processing server506. Referring to FIG. 6, ACARS messaging process 600 may begin byobtaining the IP address of message processing server (task 602). ThisIP address is necessary for connectivity to the TCP/IP network. Thedestination hostnames and IP addresses can be resolved from the aircraftmodifiable information (“AMI”) stored for the CMU. The TCP/IP portnumbers may also be configurable via the AMI, or held constant,depending upon the particular implementation. For a given airline, theIP address of message processing server 506 may vary from one airport toanother or remain constant regardless of the airport.

Item 2 represents an indication from TWLU 504 to ACARS router 502 thatwireless connectivity at a data link layer level has been established.In other words, networking protocols exercising on the TCP/IP networkmay now exchange data. At this time, ACARS messaging process 600 canestablish a TCP/IP datalink between the aircraft and message processingserver 506 (task 604). In this regard, Item 3 of the sequence diagramrepresents an attempt to create a TCP/IP connection with messageprocessing server 506 at the given IP address. In practical embodiments,the first attempt might fail due to routing information being exchangedand/or due to an unstable wireless datalink, however, multiple attemptscan be performed to ensure that a stable connection is established.

ACARS messaging process 600 encodes a handshake message into an ASN.1compliant handshake message (task 606). In practice, the handshakemessage contains content including at least an aircraft registrationnumber for the aircraft, which enables message processing server 506 toidentify the aircraft. Other information that could be contained in thehandshake message includes Tail ID, flight number, and any other datathat can help message processing server 506 determine the identity ofthe originating aircraft or CMU. The encoded handshake message can thenbe translated or otherwise formatted into an ACARS-IP handshake messagethat is TCP/IP compliant (task 608); the ACARS-IP handshake message willalso contain at least the aircraft registration number. Item 4 of thesequence diagram and task 610 of process 600 both represent thetransmission of the ACARS-IP handshake message from the CMU to messageprocessing server 506 over the TCP/IP datalink. The intent of thistransmission is to establish a communication session between the CMU andmessage processing server 506.

In response to the handshake message, message processing server 506 canperform a similar procedure to generate and transmit an ACARS-IP returnhandshake message. In the example embodiment, the ACARS-IP returnhandshake message contains a unique token/string identifier thatidentifies message processing server 506. Item 5 of the sequence diagramrepresents the transmission of the ACARS-IP return handshake messagefrom message processing server 506 to the CMU. Referring to ACARSmessaging process 600, if the CMU does not receive a return handshakemessage (query task 612), then process 600 can exit or transmit anotherhandshake message. If the return handshake message is received, thenprocess 600 continues; the TCP/IP connection can now be utilized totransmit any number of downlink messages and/or any number of uplinkmessages between the aircraft and the message processing server 506.Uplink and downlink messages can be transmitted concurrently once theTCP/IP connection has been established. Accordingly, process 600 showsseparate subprocesses for downlink and uplink message processing.

Regarding downlink messages, process 600 continues and obtains the nextACARS downlink message from a message queue or other source of ACARSmessages (task 614). An ACARS messaging system according to theinvention can be configured to take advantage of the low cost TCP/IPnetwork as follows. While the aircraft is still in flight or otherwiseincapable of establishing a TCP/IP connection as described herein,conventional ACARS downlink messages can be prioritized according totheir importance and/or time sensitivity. In this regard, criticalmessages and messages that cannot be delayed can be processed andtransmitted using conventional ACARS messaging techniques. On the otherhand, less important messages and messages that need not be deliveredimmediately can be prioritized and queued for later transmission as oneor more ACARS-IP downlink messages. An onboard message queue, which maybe realized as a data storage element, can store the messages forsubsequent transmission via the TCP/IP datalink after touchdown.

Once the TCP/IP datalink has been established, ACARS router is notifiedthat the TCP/IP subnetwork is ready for use. At this point, ACARSmessage traffic can occur, including downlink and uplink messages. Thesequence diagram shows an example processing of a downlink message,represented by Item 6 (transmitting a suitably formatted ACARS-IPdownlink message to message processing server 506 via the TCP/IPdatalink).

Referring back to ACARS messaging process 600, an ACARS downlink messagecontaining message content is preferably encoded into an ASN.1 compliantmessage containing the message content (task 616). In addition, process600 translates, converts, or otherwise formats the encoded message intoan ACARS-IP downlink message containing the message content (task 618).In the practical embodiment, ACARS router 502 processes and encapsulatesthe ACARS text message and parameters into an ASN.1 protocol data unit(“PDU”) for transmission to message processing server 506 via the TCP/IPdatalink (task 620). As mentioned above, the TCP/IP datalink may includeone or more wireless datalinks, and task 620 may transmit the ACARS-IPdownlink message via the Internet.

The ACARS-IP downlink message is received at message processing server506 (task 622), which handles the processing of the received message.Briefly, message processing server 506 functions to convert the TCP/IPpackets into any suitable format. In one embodiment, message processingserver 506 converts the TCP/IP packets into a format that isrecognizable by legacy ACARS messaging systems. Alternatively, the rawdata could be fed into other processes or systems (e.g., databases,statistical analysis routines, auto-response systems, email, memorydevices, etc.) that utilize different formats. In this regard, ACARSmessaging process 600 can perform ASN.1 decoding of the receivedACARS-IP message (task 624) and construction of a received ACARS message(task 626). Process 600 may construct the received ACARS message suchthat it again becomes compliant with the conventional ACARS format.Eventually, process 600 extracts the ACARS message content from thereceived message (task 628) and/or performs ACARS message handling (task630) in accordance with the needs and requirements of the system.

The sequence diagram also shows an example processing of an uplinkmessage, represented by Item 7. As mentioned above, a practicalembodiment may send uplink and downlink messages at any time, and thetiming shown in FIG. 5 merely represents a simplified scenario usefulfor explaining the messaging processes.

For the sake of completeness, ACARS messaging process 600 includes thepossibility of concurrent uplink message transmission. Processing of anuplink message may begin by obtaining the next ACARS uplink message froma message queue or from any suitable source associated with messageprocessing server 506 (task 632). Thereafter, process 600 proceeds withencoding the ACARS uplink message into an ASN.1 compliant message (task634). In addition, process 600 translates, converts, or otherwiseformats the encoded message into an ACARS-IP uplink message containingthe desired message content (task 636). In the practical embodiment,message processing server 506 creates one or more ASN.1 PDUs duringtasks 634 and 636. Thereafter, the ACARS-IP uplink message can betransmitted to the aircraft via the established TCP/IP datalink (task638).

The ACARS-IP uplink message is eventually received by ACARS router 502,which handles the processing of the received message. Briefly, ACARSrouter 502 functions to convert the TCP/IP packets into any suitableformat. In one embodiment, ACARS router 502 converts the TCP/IP packetsinto a format that is recognizable by legacy ACARS messaging systems.Alternatively, the raw data could be fed into other processes or systems(e.g., databases, statistical analysis routines, auto-response systems,email, memory devices, etc.) that utilize different formats. In thisregard, ACARS messaging process 600 can perform ASN.1 decoding of thereceived ACARS-IP uplink message (task 640) and construction of areceived ACARS uplink message (task 642). Process 600 may construct thereceived ACARS uplink message such that it again becomes compliant withthe conventional ACARS format. Eventually, process 600 extracts theACARS message content from the received message (task 644) and/orperforms ACARS message handling (task 646) in accordance with the needsand requirements of the system. For example, the message, depending uponthe destination, may be forwarded to other airborne end systems, such asthe flight management system of the aircraft.

After each uplink or downlink message is processed, the next message canbe handled as described above. In this regard, FIG. 6 depicts thedownlink and uplink branches as loops that facilitate the repeatedhandling of any number of messages.

EXAMPLE IMPLEMENTATION

The following is a high level design of an example ACARS messagingapplication protocol that may be utilized in connection with a practicalembodiment of the invention. It should be appreciated that this examplereflects only one possible practical implementation of the invention andthat the invention is not limited to this specific embodiment or anyparticular implementation. The system design approach on the CMU is tobypass the conventional ACARS stack and to send the ACARS “user-text”directly to the ground end system. The reason for this approach is tobypass unnecessary ACARS processing (ARINC 618/620), alleviate the needfor an ACARS air-ground ACK on a per-message basis (which alsoalleviates the lock-step limitation of the ACARS protocol), and providethe “user-text” in a format that can be understood by any ground endsystem. Processing by a data service provider on an ARINC or SITAnetwork is unnecessary with this approach.

The intent is to provide the ground end system with enough informationto display the message as if it were received from a data serviceprovider in A620 format (see Table 1 below). The ground end system willbe responsible for arranging the data for display in A620 format, or theground end system may display any or all of the information in anyformat.

A620 Downlink Message Example—An example A620 ACARS downlink message isset forth below. The intent is to provide the information that a groundend system can use to formulate the A620 message and display exactly asshown. In practice, the CMU will not send the ACARS message shown belowverbatim to the ground end system. The example downlink message isformatted as follows:

QU ORDOPUA SFOMTUA

.DSPXXXX 182111

DFD

FI UA17/AN N1313Z

DT DSP RGS 182111 D01A

-user-text

Decomposition Of Example A620 Message—Table 1 decomposes the exampleA620 ACARS message and provides an explanation of how all the necessaryinformation may be derived on a ground end system. Column 1, “620Downlink ACARS Message,” defines the field name in the A620 ACARSmessage. Column 2, “Origin,” notes where the information may be derivedfrom. “GND” means the ground end system knows this information a priori.“CMU” means this information will be provided by the CMU during theACARS messaging protocol exchange described herein. “T-CMU” meansinformation will be translated on the ground from information providedby the CMU (through the use of the ACARS messaging protocol exchangedescribed herein). Column 3, “Description,” provides direction for howthe information may be populated on the ground. The last column,“Example,” maps the information back to the A620 ACARS message example.TABLE 1 A620 Downlink ACARS Message Fields 620 Downlink ACARS MessageOrigin Description Example Priority GND Fixed - constant, priority willalways be QU QU Destination Address GND Fixed - Always theairline-supplied basic ORDOPUA address Supplemental Address GND Fixed -Supplied by ground (optional) SFOMTUA Signature (Originator Address ofGND Fixed - No DSP has been used, therefore the .DSPXXXX ServiceProvider) ground system can define this item Transmission Time CMU TimeACARS message was sent 182111 Standard Message Identifier T-CMUTranslated on ground from label and optional DFD (“SMI”) sublabel FlightIdentifier TEI GND Fixed FI Flight Identifier CMU Provided by CMU UA17Aircraft Registration Number TEI GND Fixed - constant /AN AircraftRegistration Number CMU Provided by CMU N1313Z Service Information TEIGND Fixed - constant DT Data Service Provider (“DSP”) GND Fixed - No DSPhas been used, therefore the DSP Identifier ground system can definethis item Ground Station GND No ground station has been used, thereforethe RGS ground system can define this item Message Reception Time GNDThis is usually the time provided by the DSP. 182111 Since no DSP hasbeen used, the ground system can determine this item Message SequenceNumber CMU Provided by CMU D01A Free Text TEI GND Fixed - constant-<space> Free Text CMU Message payload user-text

Note that the SMI can be determined on the ground end system by mappingthe label and sublabel of the ACARS message to the SMI. This mapping isprovided in the ARINC 620-4 specification, Appendix C. In addition, thelabel and sublabel of the ACARS message will be provided by the CMU (viathe ACARS messaging protocol exchange described above).

A620 Downlink Messaging Protocol—The following is a high levelcomposition of PDUs that can be generated by the CMU and sent to theground. TABLE 2 “CMU-Hello” PDU CMU-Hello Aircraft Registration Number

TABLE 3 “Downlink-ACARS-MSG” PDU Downlink-ACARS-MSG Flight IdentifierMessage Sequence Number Transmission Time Label Sub-Label Text (“Text”field from Table 1)

In a practical embodiment, an acknowledgement (“ACK”) PDU sent by theCMU for every PDU received from the ground is not necessary due to areliable transport system (i.e., the TCP/IP connection).

A618 Uplink Message Example—An example of a partial A618 uplink messageis set forth below. This message contains all parts after theconventional ACARS message “STX” field. As described above, the ACARSstack in the CMU is bypassed, which eliminates the need for a completeA618 header in the ACARS message. Nonetheless, issues might surface whenother end systems (e.g., LRUs such as printers or the flight managementsystem) on the aircraft expect a formatted header. Hence, it is theresponsibility of the ground end system to populate the header asdescribed in Table 4 (see below) prior to sending the ACARS message tothe CMU. This header is not always necessary, and can be determined viareference to ARINC Specification 620-4, Appendix C per a label andsublabel basis. Therefore, in certain instances, it is expected that theground will provide only the user-text as the ACARS message, and inother instances a partial A618 header will be appended to the user-textof the ACARS message. The example uplink message is formatted asfollows:

.SFOMTUA

DFD

ANN1313Z

-#DF user-text

Decomposition Of Example A618 Message—Table 4 provides a decompositionof a partial A618 ACARS message with an optional populated header and anoptional sublabel. Column 1, “Uplink ACARS Message Field,” defines thefield name in the ACARS message. Column 2, “Description,” providesdirection on how the information may be populated on the ground andwhether such information is optional. The last column, “Example,” mapsthe information back to the A618 ACARS message example. The CMU isexpecting the ACARS message to be in this format. TABLE 4 A620 UplinkACARS Message Fields Uplink ACARS Message Field Description ExampleSupplemental Should include ground station origin SFOMTUA Address name(optional header) Transmission Time ACARS message was sent 182107 Timefrom message processing server (optional header) Standard This field isused to determine the DFD Message label and optional sublabel in theIdentifier Uplink-ACARS-MSG PDU (optional (“SMI”) header) Aircraft Fixed(optional header) AN Registration Number TEI Aircraft Aircraftdestination (optional header) N1313Z Registration Number Separator Fixed(optional header) — Sublabel (optional) #DF User Text Message payload toCMU user-text

A618 Uplink Messaging Protocol—The following is a high level compositionof PDUs that can be generated by the ground end system and sent to theCMU on the aircraft. TABLE 5 “Gate-Hello” PDU Gate-Hello Unique name ofground host

TABLE 6 “Uplink-ACARS-MSG” PDU Uplink-ACARS-MSG Label Sub-Label Text(All fields from Table 4)

In a practical embodiment, an ACK PDU sent by the ground end system forevery PDU received from the CMU is not necessary due to a reliabletransport system (i.e., the TCP/IP connection).

ASN.1 Notation

As mentioned above, ASN.1 is a formal notation used for describing datatransmitted by protocols, regardless of language implementation andphysical representation of the data. A practical advantage of usingASN.1 is the existence of freeware ASN.1 compilers. ASN.1 compilersconvert ASN.1 text into C source code. The generated C code containsequivalent data structures and routines to convert values between theinternal (C source code) representation and the corresponding BasicEncoding Rules format used to transmit data to a peer.

TCP is a stream oriented protocol, which means that there is no embeddeddistinction between the end of one PDU and the start of the next.Therefore, the given application must decipher the PDUs from thereceived octet stream. An ASN.1 encoded octet stream provides thedistinction between PDUs by providing a size field in the first fewoctets of the stream. Thus, when reading an ASN.1 encoded PDU from aTCP/IP socket, the application must process the first few bytes tointerpret the total size of the packet, then read the complete PDU priorto complete interpretation.

The following is ASN.1 text that describes one example ACARS messagingprotocol as set forth above. The ASN.1 notation for a practicalapplication will vary depending upon the data to exchange, newapplication protocols to support, and other implementation specificdetails. ACARSOverInternetProtocol DEFINITIONS ::= BEGIN EXPORTS;IMPORTS; -- Basic types for AOIP protocol VersionNumber ::= [0] INTEGERAircraftRegistrationNumber ::= [1] PrintableString( SIZE( 7 ) )ICAOAddress ::= [2] BIT STRING( SIZE( 24 ) ) FlightIdentifier ::= [3]PrintableString( SIZE( 6 ) ) MessageSequenceNumber ::= [4]PrintableString( SIZE( 4 ) ) TransmissionTime ::= [5] NumericString(SIZE( 6 ) ) Label ::= [6] VisibleString( SIZE( 2 ) ) Sub-Label ::= [7]PrintableString( SIZE( 2 ) ) MessageText ::= [8] OCTET STRING( SIZE(3296 ) ) -- Supports BOP GroundHost ::= [9] VisibleString( SIZE( 128 ) )------------------------------------------- -- Protocol------------------------------------------- -- Protocol used toimplement AOIP ACARSOverIP ::= [256] CHOICE { downlink AOIPDownlinks,uplink AOIPUplinks } ------------------------------------------- --Downlinks ------------------------------------------- -- AirCraft-HelloPDU AirCraftHello ::= [64] SEQUENCE { version VersionNumber, acidAircraftRegistrationNumber, icaoaddr ICAOAddress, EXTENSION } --Downlink-ACARS-MSG PDU DownlinkACARSMessage ::= [65] SEQUENCE { flightidFlightIdentifier, msn MessageSequenceNumber, time TransmissionTime,label Label, sublabel Sub-Label, text MessageText, EXTENSION } --Downlink Union AOIPDownlinks ::= [128] CHOICE { hellomsg AirCraftHello,acarsmsg DownlinkACARSMessage, EXTENSION }------------------------------------------- -- Uplinks------------------------------------------- -- Ground Hello PDUGroundHello ::= [66] SEQUENCE { version VersionNumber, name GroundHost,EXTENSION } -- Uplink-ACARS-MSG PDU UplinkACARSMessage ::= [67] SEQUENCE{ label Label, sublabel Sub-Label, text MessageText, EXTENSION } --Uplink Union AOIPUplinks ::= [129] CHOICE { hellomsg GroundHello,acarsmsg UplinkACARSMessage, EXTENSION } END

Simulating ACARS Acknowledgments For Downlink Messages

When an ACARS messaging system according to a practical embodiment ofthe invention is utilized, the conventional ARINC/SITA network isbypassed during transmission. Consequently, the usual ACARS Network ACK(A618) is lost. External LRUs and internal CMU components, however,still expect to receive the A618 ACARS Network ACK to complete an ACARStransaction. This issue is further complicated if downlink ACARSmessages are stored (queued) for future transmission as described above,or stored for transmission when the subnetwork is down. In particular,the following issues should be resolved: (1) when to simulate an ACARSNetwork ACK to external LRUs and signal CMU internal components; and (2)prevent rerouting of ACARS messages and extraneous ACARS Network ACKS.

Processing Of ACARS Downlink Messages—The following is a summary of howan ACARS downlink message can be processed by an example embodiment ofthe ACARS messaging system. This summary will provide background for thedescription of the simulated ACK functionality.

Step 1—The aircraft modifiable information (“AMI”) will define thefollowing new attribute for each downlink message type (determined bylabel) and for each originator (LRUs or CMU originated): GateLifetime.This attribute represents the number of time increments that the ACARSmessage may age on the CMU storage device, up to a maximum time. Forexample, GateLifetime may be the number of 30-minute increments, up to amaximum of 48 hours. In practice, the storage device is a mass storagememory device coupled to an appropriate card of the CMU. If 0 isdefined, then the message should be sent immediately (no agingpermitted). If this field is set to TIME_MAX, then the message shouldnever be deleted (no aging occurs; the message will reside on the CMUstorage device until sent to the ground message server). This field isdifferent than the conventional Message Lifetime field in the AMI.

Step 2—For each downlink message, the ACARS routing function willperform the following:

(a) Use the Subnetwork preference byte and Subnetwork_Available flag todetermine if the message can be transferred via the TCP/IP datalink. TheSubnetwork_Available flag is reported to the ACARS routing function bythe ACARS messaging function when the ability to transfer ACARS messagesto the ground becomes available, and when the ability is lost.

(b) Determine how long the ACARS message should age. This should becalculated from the GateLifetime and Message Lifetime parameters fromthe AMI. The determination may simply select the shortest of these twolifetime values.

Step 3—The ACARS messaging function will perform the following:

(a) Receive downlink ACARS messages from the ACARS routing function whenthe subnetwork is not available. If the given lifetime parameter isgreater than zero, then the message is stored on the CMU storage deviceaccording to a given priority scheme.

If the given lifetime parameter is zero, then the ACARS routing functionis notified that the ACARS downlink message can't be sent.

(b) Receive downlink ACARS messages from the ACARS routing function whenthe subnetwork is available. As soon as the subnetwork becomesavailable, the ACARS router begins downloading of any ACARS messages onthe storage device to the ground system in priority order. If anyreceived ACARS message from the ACARS routing function is of higherpriority than all stored messages, then the ACARS message from the ACARSrouting function is transmitted next. If any received ACARS message fromthe ACARS routing function is of lower priority than any stored message,then store that message and continue transmitting higher prioritymessages from the storage device over the TCP/IP datalink. If thesubnetwork becomes unavailable, then check the lifetime of each storedmessage. If the lifetime equals zero (or has expired) for a given ACARSdownlink message, than discard the message.

Goals/Requirements For Simulating ACARS Network ACKs—The followingshould be considered in the practical implementation of an ACARSmessaging system as described herein.

1. Simulate ACARS Network ACKs to allow external LRUs and internal CMUcomponents to send more than one ACARS message at a time.

2. If the GateLifetime attribute is zero, than do not simulate an ACARSNetwork ACK until the message is actually received by the ground server.

3. If the subnetwork is up, then send the ACARS message immediately andsimulate an ACARS Network ACK.

4. If unable to transmit the ACARS message (e.g., the subnetwork isdown) and the GateLifetime attribute is zero, then discard the ACARSmessage and return an ACARS NAK to the ACARS router. This scenario willallow the ACARS router to re-route the ACARS message, if so desired.

5. If unable to transmit the ACARS message (e.g., the subnetwork isdown) and the GateLifetime attribute is greater than zero, then simulatean ACARS Network ACK immediately and store the ACARS message on thestorage device for later transmission.

6. If unable to transmit ACARS message (e.g., the subnetwork is down)and the GateLifetime attribute is greater than zero, then delete theACARS message when the GateLifetime attribute expires. This preventsrerouting and multiple extraneous ACARS Network ACKS.

Use Cases For Simulating ACARS Network ACKs—This section provides UseCases per our the stated goals and requirements. The following definesthe participants:

1. External LRU—LRU separate from the CMU; communicates over 429/A619.

2. ACARS Stack—ACARS implementation residing on the CMU.

3. AM—ACARS Messaging function; resides on the CMU and communicates overTCP/IP.

4. Message Server—Ground server, which is the AM peer; connected toTCP/IP network.

Note that even though all of these use cases define the interaction withan external LRU, any CMU originated ACARS messages will behave in thesame manner. In this regard, simply replace the External CMU participantwith any internal CMU participant and the use cases still perform thesame.

Case 1: Successful Downlink, Simulated ACK—FIG. 7 is a message sequencediagram that illustrates a simulated ACK procedure. This scenarioassumes the following preconditions: (1) the subnetwork is up; and (2)the GateLifetime attribute=“Don't Care.” Since the subnetwork is up, theGateLifetime parameter is irrelevant. In this example, the ACARS messagetraverses through the mass storage device (“MSD”) 702 of the CMU forpriority processing. As soon as the ACARS message is actually sent tothe ground message server 704, an “ACARS ACK” is simulated.

Case 2: ACARS Message Return For Re-Routing—FIG. 8 is a message sequencediagram that illustrates this scenario. This scenario assumes thefollowing preconditions: (1) the subnetwork is down; and (2) theGateLifetime attribute is zero (send immediately). Since the subnetworkis down and the GateLifetime attribute is zero, the ACARS messagingfunction 708 returns an “ACARS NAK” message 710 immediately to the ACARSrouter. No simulated “ACARS ACK” is necessary at this time. The messagecould be re-routed to another subnetwork (SATCOM, VHF, etc.) where aconventional ACARS Network ACK would be expected.

Case 3: Successful Delayed Downlink, Simulated ACK—FIG. 9 is a messagesequence diagram that illustrates this scenario. The followingpreconditions apply to this case: (1) the subnetwork is down; and (2)the GateLifetime attribute is greater than zero (store the message onMSD 702 if the subnetwork is unavailable). Since the GateLifetimeattribute is greater than zero, the system simulates an ACARS NetworkACK 706 immediately and there is no need to wait for successfultransmission of the ACARS Message. The stored ACARS message issuccessfully transmitted at a later time, but prior to the expiration ofthe GateLifetime parameter.

Case 4: Unsuccessful Downlink, Simulated ACK—FIG. 10 is a messagesequence diagram that illustrates this scenario. The followingpreconditions apply to this case: (1) the subnetwork is down; (2) theGateLifetime attribute is greater than zero (store the message on MSD702 if the subnetwork is unavailable); and (3) the subnetwork does notresurrect within the period defined by the GateLifetime attribute. Sincethe GateLifetime attribute is greater than zero, the system simulates anACARS Network ACK 706 immediately and there is no need to wait forsuccessful transmission of the ACARS Message. Assuming that theGateLifetime parameter has expired, the ACARS message gets deleted fromMSD 702. In this case, the ACARS message is not delivered to messageserver 704, and other measures can be taken to ensure transmission ofthe message.

Processing for the ACARS Router

The following implementation notes refer to one practical embodiment ofthe ACARS message system described herein. Of course, an actualimplementation of the system can vary according to the needs andrequirements of the particular deployment.

Downlink ACARS Messages:

1. Messages will be deemed worthy of subnetwork transmission by someinternal method.

2. A619 processing will occur on the ACARS router prior to the messagebeing transferred for further processing. Such further processing mayinclude, for example, A619 header stripping and A619 application ACKs.

3. ACARS messages will not be segmented.

4. If appropriate, ACARS messages can be encrypted prior to ACARS routerprocessing.

5. Subnetwork worthy messages should be processed and sent immediately.Queuing is not necessary and immediate transfer to the storage device isperformed. Queuing is maintained on the storage device coupled to theACARS router. Since the storage device functions as a hard disk forstorage of subnetwork-bound ACARS messages, power transients or otherpower disruptions will not result in loss of these ACARS messages.

6. The parameters of a downlink ACARS message to be transferred include:user-text, label, sublabel, message sequence number, and FlightIdentifier. It is assumed that the user-text parameter may be encrypted,but the other parameters will not be encrypted.

Uplink ACARS Messages:

1. For a message destined to an airborne end system (e.g., the flightmanagement system), A619 processing can occur after the message has beenreceived by the ACARS router. Such processing may include, for example,appending an A619 header and receiving A619 application ACKs.

2. ACARS messages will not be received in segmented form (in multipleblocks). If the true destination is an LRU over Character OrientedProtocol 429 and the message text is greater than 220 octets (oneblock), then some post-processing will need to be performed tomanipulate the message text into appropriate sized blocks. The“post-processing” may be performed by any suitable processing element ofthe ACARS router, and the location of such processing is animplementation decision.

3. ACARS messages may be received in encrypted form. If encrypted, themessages will be decrypted by the ACARS router.

4. The parameters of an uplink ACARS message to be transferred to theACARS router include: user-text, label, and sublabel. It is assumed thatthe user-text parameter may be encrypted, but the other parameters willnot be encrypted.

5. Any message received from the ground system via the subnetwork willnot require an A618 ACARS ACK due to the bypassing of the airborne ACARSstack and the ground-based data service provider.

Processing For The Message Processing Ground Server

1. The message processing server should support one TCP/IP connectionper aircraft.

2. The aircraft will initiate the TCP/IP connection to the messageprocessing server when the subnetwork is available.

3. The message processing server will support multiple TCP/IPconnections (dependent on the number of aircraft at airport gates at anyone time).

4. The message processing server will to exercise the ACARS messagingprotocol as set forth in more detail above.

5. The message processing server will populate and interpret the PDUs asdescribed in more detail above.

6. If appropriate, the message processing server will perform encryptionand decryption processing of the text field. Other fields need not beencrypted.

7. The message text will not be segmented. The CMU can support a textfield up to 3296 octets (per ARINC 619) for use with Bit OrientedProtocol.

8. The text field of a Downlink-ACARS-MSG PDU may contain multiplesupplemental addresses. The message processing server will eitherdistribute these messages as appropriate, or disallow messages with morethan one supplemental address.

9. Downlink ACARS messages with label QA through QT depend on theARINC/SITA data service provider to provide certain formatting of themessages prior to delivery to the destination. Since the ACARS messagingsystem described herein does not rely on a data service provider whenthe subnetwork is used, the message processing server will provide thissame type of formatting. The message processing server will determinewhether this formatting is appropriate; if not, it will forgo the extraprocessing and simply alert the end user that the text will be seen inits raw format.

10. The message processing server will need to manage lost connectionsto the aircraft (either graceful disconnects, or TCP/IP connectiontimeouts).

While at least one exemplary embodiment has been presented in theforegoing detailed description, it should be appreciated that a vastnumber of variations exist. It should also be appreciated that theexemplary embodiment or exemplary embodiments are only examples, and arenot intended to limit the scope, applicability, or configuration of theinvention in any way. Rather, the foregoing detailed description willprovide those skilled in the art with a convenient road map forimplementing the exemplary embodiment or exemplary embodiments. Itshould be understood that various changes can be made in the functionand arrangement of elements without departing from the scope of theinvention as set forth in the appended claims and the legal equivalentsthereof.

1. An ACARS messaging method comprising: obtaining an ACARS messagecontaining message content; encoding said ACARS message into an ASN.1compliant message containing said message content; translating saidASN.1 compliant message into an ACARS-IP message containing said messagecontent, said ACARS-IP message being compliant with the TCP/IP suite ofprotocols; and transmitting said ACARS-IP message between an aircraftand a message processing server via a TCP/IP datalink.
 2. A methodaccording to claim 1, wherein said ACARS-IP message is a downlinkmessage.
 3. A method according to claim 1, further comprising:prioritizing in-flight ACARS downlink messages; and queuing, in responseto said prioritizing step, one or more of said in-flight ACARS downlinkmessages for transmission as one or more ACARS-IP downlink messages. 4.A method according to claim 1, wherein said ACARS-IP message is anuplink message.
 5. A method according to claim 1, wherein saidtransmitting step transmits said ACARS-IP message via at least onewireless TCP/IP datalink.
 6. A method according to claim 1, wherein saidtransmitting step transmits said ACARS-IP message via the Internet.
 7. Amethod according to claim 1, wherein transmitting said ACARS-IP messageoccurs after touchdown of said aircraft.
 8. A method according to claim1, further comprising establishing said TCP/IP datalink.
 9. An ACARSmessaging system comprising: means for obtaining an ACARS messagecontaining message content; means for encoding said ACARS message intoan ASN.1 compliant message containing said message content; means fortranslating said ASN.1 compliant message into an ACARS-IP messagecontaining said message content, said ACARS-IP message being compliantwith the TCP/IP suite of protocols; and means for transmitting saidACARS-IP message between an aircraft and a message processing server viaa TCP/IP datalink.
 10. A system according to claim 9, wherein saidTCP/IP datalink comprises at least one wireless TCP/IP datalink.
 11. Amethod according to claim 9, further comprising: means for prioritizingin-flight ACARS downlink messages to obtain prioritized messages; andmeans for queuing said prioritized messages for transmission as one ormore ACARS-IP downlink messages.
 12. A downlink ACARS messaging methodcomprising: establishing a TCP/IP datalink between an aircraft and amessage processing server; encoding a handshake message containing anaircraft registration number for said aircraft into an ASN.1 complianthandshake message containing said aircraft registration number;translating said ASN.1 compliant handshake message into an ACARS-IPhandshake message containing said aircraft registration number, saidACARS-IP handshake message being compliant with the TCP/IP suite ofprotocols; and transmitting said ACARS-IP handshake message to saidmessage processing server via said TCP/IP datalink.
 13. A methodaccording to claim 12, wherein said ACARS-IP handshake message isgenerated in response to an ACARS message containing message content,said message content comprising said aircraft registration number.
 14. Amethod according to claim 12, further comprising: generating an ACARS-IPdownlink message containing a message payload, said ACARS-IP downlinkmessage being compliant with the TCP/IP suite of protocols; andtransmitting said ACARS-IP downlink message to said message processingserver via said TCP/IP datalink.
 15. A method according to claim 14,wherein said ACARS-IP downlink message is generated in response to anACARS message containing message content, said message contentcomprising said message payload.
 16. A method according to claim 14,wherein said message payload comprises one or more of the following: aflight identifier; a message sequence number; a transmission timeindicator; an alphanumeric text message; and a standard messageidentifier label.
 17. A method according to claim 14, wherein saidACARS-IP downlink message is generated in response to an ASN.1 encodedACARS message containing message content, said message contentcomprising said message payload.
 18. A method according to claim 12,further comprising obtaining an IP address for said message processingserver prior to establishing said TCP/IP datalink.
 19. A methodaccording to claim 12, wherein establishing said TCP/IP datalink occursafter touchdown of said aircraft.
 20. An uplink ACARS messaging methodcomprising: establishing a TCP/IP datalink between an aircraft and amessage processing server; encoding a handshake message containing anidentifier for said message processing server into an ASN.1 complianthandshake message containing said identifier; translating said ASN.1compliant handshake message into an ACARS-IP handshake messagecontaining said identifier, said ACARS-IP handshake message beingcompliant with the TCP/IP suite of protocols; and transmitting saidACARS-IP handshake message to said aircraft via said TCP/IP datalink.21. A method according to claim 20, further comprising: generating anACARS-IP uplink message containing a message payload, said ACARS-IPuplink message being compliant with the TCP/IP suite of protocols; andtransmitting said ACARS-IP uplink message to said aircraft via saidTCP/IP datalink.
 22. A method according to claim 21, wherein saidACARS-IP uplink message is generated in response to an ACARS messagecontaining message content, said message content comprising said messagepayload.
 23. A method according to claim 21, wherein said messagepayload comprises one or more of the following: a supplemental address;a transmission time indicator; a standard message identifier label; anaircraft registration number for said aircraft; and an alphanumeric textmessage.
 24. A method according to claim 21, wherein said ACARS-IPuplink message is generated in response to an ASN.1 encoded ACARSmessage containing message content, said message content comprising saidmessage payload.
 25. A method according to claim 20, further comprisingobtaining an IP address for said aircraft prior to establishing saidTCP/IP datalink.
 26. A method according to claim 20, whereinestablishing said TCP/IP datalink occurs after touchdown of saidaircraft.
 27. An ACARS messaging method comprising: establishing aTCP/IP datalink between an aircraft and a message processing server;obtaining an ACARS message containing message content; encoding saidACARS message into an ASN.1 compliant message containing said messagecontent; translating said ASN.1 compliant message into an ACARS-IPmessage containing said message content, said ACARS-IP message beingcompliant with the TCP/IP suite of protocols; transmitting said ACARS-IPmessage via said TCP/IP datalink; receiving said ACARS-IP message toobtain a received ACARS-IP message; and extracting said message contentfrom said received ACARS-IP message.
 28. A method according to claim 27,further comprising constructing a received ACARS message in response tosaid received ACARS-IP message.
 29. A method according to claim 28,wherein constructing a received ACARS message comprises performing ASN.1decoding on said received ACARS-IP message.
 30. A method according toclaim 27, wherein said transmitting step transmits said ACARS-IP messagevia at least one wireless TCP/IP datalink.
 31. A method according toclaim 27, wherein said transmitting step transmits said ACARS-IP messagevia the Internet.
 32. A method according to claim 27, whereintransmitting said ACARS-IP message occurs after touchdown of saidaircraft.
 33. An ACARS messaging system for an aircraft, said systemcomprising: a ACARS router; an onboard data communication element forsaid ACARS router, said data communication element being configured toestablish a TCP/IP datalink between said aircraft and a messageprocessing server; said ACARS router being configured to encode an ACARSmessage into an ASN.1 compliant message containing message content andto translate said ASN.1 compliant message into an ACARS-IP messagecontaining said message content, said ACARS-IP message being compliantwith the TCP/IP suite of protocols; and said data communication elementbeing configured to transmit said ACARS-IP message between said aircraftand said message processing server via said TCP/IP datalink.
 34. Asystem according to claim 33, wherein said data communication element isconfigured to transmit said ACARS-IP message via at least one wirelessTCP/IP datalink.
 35. A system according to claim 33, wherein said datacommunication element comprises a terminal area wireless LAN unit.
 36. Asystem according to claim 33, wherein said ACARS router is furtherconfigured to: prioritize in-flight ACARS downlink messages to obtainprioritized messages; and queue said prioritized messages fortransmission as one or more ACARS-IP downlink messages.
 37. A systemaccording to claim 33, wherein said data communication element transmitssaid ACARS-IP message via the Internet.